Advanced Debug Tips

Further reading: AppVeyor - A good continuous integration system is a joy to behold

How to use CI Tools

Bdbcat has responded to several questions, explaining how these features should be used.

1. How to get Alpha/Beta Testers familiar with Github and locating those compiled files?

2. Are these eventually going to be the source for the Website Downloads page?

Summary

Testing a CI Product is like sneaking a spoon-sip of the dinner simmering on the stove while Mom is not looking. She knows it needs salt, and is way too hot to eat yet. If you drop dead immediately, she wants to know about it. Otherwise, she wants to not hear too many comments. Wait until it comes to the table. Meanwhile, go outside and play….

Dave

How CI Tools work

Using an example from Sean's Weatherfax plugin.

For Windows, use Appveyor.

1. Go to Sean's Weatherfax_pi github repository

https://github.com/seandepagnier/weatherfax_pi

2. Click on the Code Tab

Select the “Branch” you want to be on, most of the time it will be “master”

CI-1

https://github.com/seandepagnier/weatherfax_pi/commits/master

CI-2

4. Find the most recent commit

Lets say it is “yet more inlines” from Feb 11 2018

5. Click on the Green Check at the end

A popup for the Continuous Integration Links for TravisCI and AppVeyor come up.

CI-3

6. Click on AppVeyor "Details"

The page will come up with the “Console” Tab.

https://ci.appveyor.com/project/seandepagnier/weatherfax-pi/build/1.0.13

CI-4

7. Click on the "Artifacts" Tab

To get to the download executable.

https://ci.appveyor.com/project/seandepagnier/weatherfax-pi/build/1.0.13/artifacts

CI-5

You should then be able to download the weatherfax_pi-1.8.001-win32.exe by clicking on it.

Push build to Git Repository with a push tag

In both .travis and appveyor it is possible to initiate the push of a build to your Git repository.

.travis

For travis refer to Petri's post #637

You can use it as it is, the MacOSX part was helped to package FAI (fully automated installation) by Nereus32 here. The two build target conditional variables are courtesy from Sean d'Epagnier from whom I have shamelessly stolen that part. But that's not all, you are certainly better aware than I am about the different Cmake include files in cmake-directory. In this case, there is a small modification for Mac in packaging, courtesy of Nereus32. Anyway, it takes for a while before, for each commit, both Linux and Mac builds correctly. There is no point to continue before they do.

You need a travis CLI (command line interface). It is needed to encrypt the GitHub token. The encrypted string is put in your personal .travis.yml file. Unlike in AppVeyor, there is no on-line service for it, not that I know. That's why you need to start with travis CLI installation. Here are some installation instructions for Windows, I used Linux where the installation was straightforward.

When you are sure that you have travis CLI up and working, you can start to create the encrypted key. Without it, deployment to GitHub does not work. 

  Create an API token for travis in GitHub here https://github.com/settings/tokens (Developer tools). Select all rights to repository and repository only (that's enough - if it does not work, it is something else). Don't close the window, or make sure you have copied the key to your computer.
  Open command window and give following command (in Linux) with travis CLI:
  echo pasteGitHubTokenHere | travis encrypt -r rgleason/reponameHere --org
  It gives you out a very long arbitrary string in format "1234abcde....f". You need to copy and paste it in .travis.yml in secure field as one single line. Don't let your editor to break it on different lines.
  Warning: you will find from the wonderful interweb instructions which are supposed to modify the .travis.yml on the fly. Believe me, I tried and they screwed up completely the file. Stick to copy-paste.

When you commit .travis.yml file, the travis build starts. It is good to check that both of its build processes do pass faultlessly before the next step.

In GitHub create a repository, like v1.2.3 as tag, description is free but it is good to contain the version. Here is where Travis and AppVeyor both deploy the built contents. When you hit the create button it is a sign for Travis and AppVeyor to start the build which will end up with deployment (the condition flags in the configuration file are defining this. That's why it is important that you check before you create the repository that all builds do pass faultlessly, you will not get a second chance but you need to create a new repository. (Repositories cannot be deleted since they are, in fact defined by tags.)

If you observe 401 error at the deployment phase in travis logs search in google.com with the following phrase for possible causes “travis github https://api.github.com/user: 401 - bad credentials”

for Appveyor

For appveyor refer to

Git push origin [tag] like“v1.9.1-ov42” can now result in Appveyor push via webhooks (read, write) to a new Github Release. See Use of appveyor 'auth_token' to push a new github release

And PR appveyor auth_token, changes, version 1.9.2 ov42 #135

Use of appveyor 'auth_token' to push a new github release #134

Getting auth token

Push Appveyor artifact file to a new Github release

https://github.com/seandepagnier/weatherfax_pi/issues/134

– I have commented out the tag: $(appveyor_repo_tag_name) and (appveyor_repo_tag):true which create the version number and deploy on tag push only.

This is the appveyor.yml file used for weatherfax_pi at this point, will push every new file up to Release. The security token used is encrypted by yaml and can only be used on my repository. appveyor.yml.txt https://github.com/seandepagnier/weatherfax_pi/files/3112304/appveyor.yml.txt

Uncommented these lines in appveyor.yml: 

  tag: $(APPVEYOR_REPO_TAG_NAME) # insert version name
  APPVEYOR_REPO_TAG: true # deploy on tag push only

Then pushed appveyor.yml to remote. Then pushed a new tag to remote with: 

  git tag v1.9.3-ov42-test
  git push origin v1.9.3-ov42-test

1. git tag v1.13.1 2. git push origin v1.13.1 3. git push –delete origin v1.13.1 4. git tag –delete v1.13.1

upon which a new Release & Tag “v1.9.3-ov42-test” gets created which now contains the results of the Appveyor build under “Assets” find “weatherfax_pi-1.9.3-ov42-win32.exe”. See https://github.com/rgleason/weatherfax_pi/releases/tag/v1.9.3-ov42-test

The Appveyor Console shows: https://ci.appveyor.com/project/rgleason/weatherfax-pi

Collecting artifacts… Found artifact 'build\weatherfax_pi-1.9.3-ov42-win32.exe' matching 'build\*.exe' path Uploading artifacts… [1/1] build\weatherfax_pi-1.9.3-ov42-win32.exe (721,873 bytes)…100% Deploying using GitHub provider Creating “v1.9.3-ov42-test” release for repository “rgleason/weatherfax_pi” tag “v1.9.3-ov42-test” commit “05b6418e674b7d722424146c8efe2745a88b635b”…OK Uploading “weatherfax_pi-1.9.3-ov42-win32.exe” to release assets…OK Build success

This is the appveyor.yml that is used used currently (it may change a little) appveyor.yml.txt 

  If appveyor succeeds in creation of an Artifact - green check.
  If appveyor succeeds in creation of an Artifact and a Release (if a new Tag is pushed to remote.) - green check.
  Note that VERSION.cmake entries/changes and TAG must be manually coordinated!

For more information about setting the auth_token security please read the notes made in appveyor discussions: *Push built Artifact .exe to Github “Release” (opensource, public repos, dev account) See Post 13 Posted by fcgleason on Apr 23, 2019 @ 09:31 PM Also see Git branch –delete and Git Squash -Effect on Appveyor might be useful.

https://help.appveyor.com/discussions/problems/23134-push-built-file-to-opensource-public-github-release#comment_47202099

https://help.appveyor.com/discussions/questions/36997-git-branch-delete-and-git-squash-effect-on-appveyor

I am going to make a another new branch “deploy-win3” and clean up with git rebase -i HEAD~xxx Then make a PR to Sean. To get this working Sean will have to add his own encrypted auth_token.

This ov42 appveyor file will still work to create Artifacts, even if the auth_token is not changed. @rgleason rgleason referenced this issue 18 days ago Open appveyor auth_token, changes, version 1.9.2 ov42 #135

https://github.com/seandepagnier/weatherfax_pi/pull/135

It just updates the patch number and updates the Appveyor file so that we can push a new tag to the remote repository and then appveyor will push the windows artifact into the Release (new tag). (This just requires the setup of a personnal auth_token and copying the Yaml encrypted version of that into the appveyor file.)

I've tested it and it seems to work fine. It's a nice efficient way to make a release with an identical tag. This is what I've done on my repository: 

  In your github account setup your own github personnal auth_token, (copy the token to somewhere).
  Go to your appveyor account encrypt the personnal auth_token, take that code an put it in the appveyor.yml file. No it should work.
  Change VERSION.cmake patch number and date, commit and push.
  Push a new tag (eg: git push origin v1.9.1-ov50), then Appveyor will build the artifact ( *exe) again and push the file to a new Github Release using the tag (eg: v1.9.1-ov50)

If you can accept this PR, I will then make another PR that updates appveyor to compile for Opencpn 5.0 If you can get thee security token working and push a new tag, that pushes the windows plugin_pi.exe file to the Release Directory, then we can have K link to that.

The next improvement would be to get travis or avppeyor to build MacOS and push that to same Release.

PS: I found out that you cannot include TAGS in a PULL REQUEST. Tags can be pushed and removed from a Remote or Local Repository, but Tags must be made by the author of the repository. In other words I cannot make a Tag for your repository by including one in a PR.

1 In your github account setup your own github personnal auth_token, (copy the token to somewhere).

2 Go to your appveyor account encrypt the personnal auth_token, take that code an put it in the appveyor.yml file. No it should work.

3 Change VERSION.cmake patch number and date, commit and push.

4. Push a new tag 

git tag v1.9.1-ov50
git push origin v1.9.1-ov50

5 Then Appveyor will build the artifact ( *exe) again and push the file to a new Github Release using the tag (eg: v1.9.1-ov50)

appveyor_auth_token_weather_routing personal token : scope repo and gist check 327e62b881282654f8cd34039ca46264b83a4403 environment: 

my_variable:
  secure: Vk+FNwtmUELJOqrUp9biHAL9KG1AcrlFr+d4pNh54e7PEVpn+s5AcsGSqV0WxaFZ

appveyor_auth_token_climatology 1789a655ae8c6221edcd22c6a28edd3e468ab30a environment: 

my_variable:
  secure: A7rMxzUbQoDkwCjKK/EuiN86GuwtObhIhdyg2cR0AJHogoIn2wepvUgrI4Pmd9It

appveyor_auth_token_autopilot_route 92e6b2a46572243fde0f9663b1c1a0681b6d068f environment: 

my_variable:
  secure: XUXtJgiO9LSQ4pAFe8/UyBIjlnMAnNfVVF0eKh48ZV9FpZSD7JydvQ3VUIdDGcRq